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Abstract 
This document replaces RFC 7321, "Cryptographic Algorithm 
Implementation Requirements and Usage Guidance for Encapsulating 
Security Payload (ESP) and Authentication Header (AH)". The goal of 
this document is to enable ESP and AH to benefit from cryptography 
that is up to date while making IPsec interoperable. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8221. 
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Copyright Notice 


Copyright (c) 2017 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(https://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


The Encapsulating Security Payload (ESP) [RFC4303] and the 
Authentication Header (AH) [RFC4302] are the mechanisms for applying 
cryptographic protection to data being sent over an IPsec Security 
Association (SA) [RFC4301]. 


This document provides guidance and recommendations so that ESP and 
AH can be used with cryptographic algorithms that are up to date. 

The challenge of such documents is making sure that, over time, IPsec 
implementations can use secure and up-to-date cryptographic 
algorithms while keeping IPsec interoperable. 


1.1. Updating Algorithm Implementation Requirements and Usage Guidance 


The field of cryptography evolves continuously: new, stronger 
algorithms appear, and existing algorithms are found to be less 
secure than originally thought. Therefore, algorithm implementation 
requirements and usage guidance need to be updated from time to time 
to reflect the new reality. The choices for algorithms must be 
conservative to minimize the risk of algorithm compromise. 
Algorithms need to be suitable for a wide variety of CPU 
architectures and device deployments ranging from high-end bulk 
encryption devices to small, low-power Internet of Things (IoT) 
devices. 


The algorithm implementation requirements and usage guidance may need 
to change over time to adapt to the changing world. For this reason, 
the selection of mandatory-to-implement algorithms was removed from 
the main Internet Key Exchange Protocol Version 2 (IKEv2) 
specification [RFC7296] and placed in a separate document. 


1.2. Updating Algorithm Requirement Levels 


The mandatory-to-implement algorithm of tomorrow should already be 
available in most implementations of AH/ESP by the time it is made 
mandatory. This document attempts to identify and introduce those 
algorithms for future mandatory-to-implement status. There is no 
guarantee that the algorithms in use today may become mandatory in 
the future. Published algorithms are continuously subjected to 
cryptographic attack and may become too weak or could become 
completely broken before this document is updated. 


This document only provides recommendations for the mandatory-to- 
implement algorithms and "too weak" algorithms that are recommended 
not to be implemented. As a result, any algorithm listed at the 
IPsec IANA registry that is not mentioned in this document MAY be 
implemented. It is expected that this document will be updated over 
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time and future versions will only mention algorithms that have 
evolved in status. For clarification, when an algorithm has been 
mentioned in [RFC7321], this document states explicitly the update of 
the status. 


Although this document updates the algorithms to keep the AH/ESP 
communication secure over time, it also aims at providing 
recommendations so that AH/ESP implementations remain interoperable. 
AH/ESP interoperability is addressed by an incremental introduction 
or deprecation of algorithms. In addition, this document also 
considers the new use cases for AH/ESP deployment, such as IoT. 


It is expected that deprecation of an algorithm be performed 
gradually. This provides time for various implementations to update 
their implemented algorithms while remaining interoperable. Unless 
there are strong security reasons, an algorithm is expected to be 
downgraded from MUST to MUST- or SHOULD, instead of MUST NOT (see 
Section 2). Similarly, an algorithm that has not been mentioned as 
mandatory-to-implement is expected to be introduced with a SHOULD 
instead of a MUST. 


The current trend toward IoT and its adoption of AH/ESP requires this 
specific use case to be taken into account as well. IoT devices are 
resource-constrained devices, and their choice of algorithms is 
motivated by minimizing the footprint of the code, the computation 
effort, and the size of the messages to send. This document 
indicates "(IoT)" when a specified algorithm is specifically listed 
for IoT devices. Requirement levels that are marked as "IoT" apply 
to IoT devices and to server-side implementations that might 
presumably need to interoperate with them, including any general- 
purpose VPN gateways. 


1.3. Document Audience 


The recommendations of this document mostly target AH/ESP 
implementers as implementations need to meet both high security 
expectations as well as high interoperability between various vendors 


and with different versions. Interoperability requires a smooth move 
to more secure cipher suites. This may differ from a user point of 
view that may deploy and configure AH/ESP with only the safest cipher 
suite. 


This document does not give any recommendations for the use of 
algorithms, it only gives recommendations for implementations. The 
use of algorithms by a specific user is dictated by their own 
security policy requirements, which are outside the scope of this 
document. 
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The algorithms considered here are listed by IANA as part of the 
IKEv2 parameters. IKEvl is out of scope of this document. IKEvl is 
deprecated; the recommendations of this document must not be 
considered for IKEvl, nor may IKEvl parameters be considered by this 
document. 


The IANA registry for "Internet Key Exchange Version 2 (IKEv2) 
Parameters" contains some entries that are not for use with ESP or 
AH. This document does not modify the status of those algorithms. 


2. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


We define some additional terms here: 


SHOULD+ This term means the same as SHOULD. However, it is likely 
that an algorithm marked as SHOULD+ will be promoted at 
some future time to be a MUST. 

SHOULD- This term means the same as SHOULD. However, an algorithm 
marked as SHOULD- may be deprecated to a MAY in a future 
version of this document. 

MUST- This term means the same as MUST. However, we expect at 
some point that this algorithm will no longer be a MUST in 
a future document. Although its status will be determined 
at a later time, it is reasonable to expect that if a 
future revision of a document alters the status of a MUST- 
algorithm, it will remain at least a SHOULD or a SHOULD- 
level. 

IoT The Internet of Things. 


3. Manual Keying 


Manual keying SHOULD NOT be used, as it is inherently dangerous. 
Without any secure keying protocol, such as IKE, IPsec does not offer 
Perfect Forward Secrecy (PFS) protection; there is no entity to 
ensure the refreshing of session keys, the tracking of Security 
Parameter Index (SPI) uniqueness, and the single use of nonces, 
Initialization Vectors (IVs), and counters. This document was 
written for deploying ESP/AH using IKE [RFC7296] and assumes that 
keying happens using IKEv2 or higher. 
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If manual keying is used regardless, Counter Mode algorithms such as 
ENCR_AES_CTR, ENCR_AES_CCM, ENCR_AES_ GCM, and ENCR_CHACHA20_POLY1305 
MUST NOT be used, as it is incompatible with a secure and persistent 
handling of the counter (as explained in the Security Considerations 
section of [RFC3686]). This particularly applies to IoT devices that 
have no state across reboots. At the time of writing, ENCR_AES_CBC 
is the only mandatory-to-implement encryption algorithm suitable for 
manual keying. 


4. Encryption Must Be Authenticated 


Encryption without authentication is not effective and MUST NOT be 
used. IPsec offers three ways to provide both encryption and 
authentication: 


o ESP with an Authenticated Encryption with Associated Data (AEAD) 
cipher 


o ESP with a non-AEAD cipher + authentication 
o ESP with a non-AEAD cipher + AH with authentication 


The fastest and most modern method is to use ESP with a combined mode 
cipher, such as an AEAD cipher, that handles encryption/decryption 
and authentication in a single step. In this case, the AEAD cipher 
is set as the encryption algorithm, and the authentication algorithm 
is set to none. Examples of this are ENCR_AES_GCM_16 and 
ENCR_CHACHA20_POLY1305. 


A more traditional approach is to use ESP with an encryption and an 
authentication algorithm. This approach is slower, as the data has 
to be processed twice: once for encryption/decryption and once for 
authentication. An example of this is ENCR_AES_ CBC combined with 
AUTH_HMAC_SHA2_512_ 256. 


The last method that can be used is ESP+AH. This method is NOT 
RECOMMENDED. It is the slowest method and also takes up more octets 
due to the double header of ESP+AH. This results in a smaller 
effective MTU for the encrypted data. With this method, ESP is only 
used for confidentiality without an authentication algorithm, and a 
second IPsec protocol of type AH is used for authentication. An 
example of this is ESP with ENCR_AES_ CBC with AH with 
AUTH_HMAC_SHA2_512_ 256. 


Wouters, et al. Standards Track [Page 6] 


RFC 8221 ESP and AH Algorithm Requirements October 2017 


5. ESP Encryption Algorithms 


4------------------------- 4+------------ 4+--------- 4---------------- + 
| Name | Status | AEAD | Comment 
4------------------------- 4------------ 4+--------- 4+---------------- + 
| ENCR_DES_IV64 | MUST NOT | No | UNSPECIFIED 
| ENCR_DES | MUST NOT | No | [RFC2405] 
| ENCR_3DES | SHOULD NOT | No | [RFC2451] 
ENCR_BLOWFISH MUST NOT No | [RFC2451] 
ENCR_3IDEA MUST NOT | No UNSPECIFIED 

| ENCR_DES_IV32 | MUST NOT | No | UNSPECIFIED 

| ENCR_NULL | MUST | No | [RFC2410] 

| ENCR_AES_CBC | MUST | No | [RFC3602] [1] 

| ENCR_AES_CCM_8 | SHOULD | Yes | [RFC4309] (IoT) | 

| ENCR_AES_GCM_16 | MUST | Yes | [RFC4106] [1] 

| ENCR_CHACHA20_POLY1305 | SHOULD | Yes | [RFC7634] 

4------------------------- 4+------------ 4+--------- 4+---------------- + 
[1] - This requirement level is for 128-bit and 256-bit keys. 192-bit 

keys remain at the MAY level. 

(IoT) - This requirement is for interoperability with IoT. Only 


128-bit keys are at the given level. 


IPsec sessions may have very long lifetime and carry multiple 
packets, so there is a need to move to 256-bit keys in the long term. 
For that purpose, the requirement level for 128-bit keys and 256-bit 
keys is MUST (when applicable). In that sense, the status for 
256-bit keys has been raised from MAY in [RFC7321] to MUST. 


IANA has allocated codes for cryptographic algorithms that have not 
been specified by the IETF. Such algorithms are noted as 
UNSPECIFIED. Usually, the use of these algorithms is limited to 
specific cases, and the absence of specification makes 
interoperability difficult for IPsec communications. These 
algorithms were not mentioned in [RFC7321], and this document 
clarifies that such algorithms MUST NOT be implemented for IPsec 
communications. 


Similarly, IANA also allocated code points for algorithms that are 
not expected to be used to secure IPsec communications. Such 
algorithms are noted as non-IPsec. As a result, these algorithms 
MUST NOT be implemented. 


Various ciphers that are older, not well tested, and never widely 
implemented have been changed to MUST NOT. 
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ENCR_3DES status has been downgraded from MAY in [RFC7321] to SHOULD 
NOT. ENCR_CHACHA20_POLY1305 is a more modern approach and 
alternative for ENCR_3DES than ENCR_AES_ CBC, and so it is expected to 
be favored to replace ENCR_3DES. 


ENCR_BLOWFISH has been downgraded to MUST NOT as it has been 
deprecated for years by TWOFISH, which is not standardized for ESP 
and therefore not listed in this document. Some implementations 
support TWOFISH using a private range number. 


ENCR_NULL status was set to MUST in [RFC7321] and remains a MUST to 
enable the use of ESP with only authentication, which is preferred 
over AH due to NAT traversal. ENCR_NULL is expected to remain MUST 
by protocol requirements. 


ENCR_AES_CBC status remains at MUST. ENCR_AES_ CBC MUST be 
implemented in order to enable interoperability between 
implementations that followed [RFC7321]. However, there is a trend 
for the industry to move to AEAD encryption, and the overhead of 
ENCR_AES_CBC remains quite large, so it is expected to be replaced by 
AEAD algorithms in the long term. 


ENCR_AES_CCM_8 status was set to MAY in [RFC7321] and has been raised 
from MAY to SHOULD in order to interact with IoT devices. As this 
case is not a general use case for VPNs, its status is expected to 
remain as SHOULD. 


ENCR_AES_GCM_16 status has been updated from SHOULD+ to MUST in order 
to favor the use of authenticated encryption and AEAD algorithms. 
ENCR_AES_GCM_16 has been widely implemented for ESP due to its 
increased performance and key longevity compared to ENCR_AES_ CBC. 


ENCR_CHACHA20_POLY1305 was not ready to be considered at the time of 
[RFC7321]. It has been recommended by the Crypto Forum Research 
Group (CFRG) and others as an alternative to AES-CBC and AES-GCM. At 
the time of writing, there are not enough ESP implementations of 
ENCR_CHACHA20_POLY1305 to be able to introduce it at the SHOULD+ 
level. Its status has been set to SHOULD and is expected to become 
MUST in the long term. 
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6. ESP and AH Authentication Algorithms 


Authentication algorithm recommendations in this section are 
targeting two types of communications: 


o Authenticated-only communications without encryption, such as ESP 
with NULL encryption or AH communications. 


o Communications that are encrypted with a non-AEAD algorithm that 
MUST be combined with an authentication algorithm. 


4+------------------------ 4---------------- 4------------------------- + 

| Name | Status | Comment | 

4+------------------------ 4---------------- 4------------------------- + 

| AUTH_NONE | MUST / | [RFC7296] [RFC5282] 

| | MUST NOT | AEAD-only 
AUTH_HMAC_MD5_96 MUST NOT [RFC2403] [RFC7296] 

| AUTH_HMAC_SHA1_96 | MUST- | [RFC2404] [RFC7296] 

| AUTH_DES_MAC | MUST NOT | UNSPECIFIED 

| AUTH_KPDK_MD5 | MUST NOT | UNSPECIFIED 

| AUTH_AES_XCBC_96 | SHOULD / MAY | [RFC3566] [RFC7296] | 

| (IoT) | 

| AUTH_AES_128_GMAC MAY [RFC4543] 

| AUTH_AES_256_GMAC | MAY | [RFC4543] 

| AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] 

| AUTH_HMAC_SHA2_512_256 | SHOULD | [RFC4868] 

4+------------------------ 4+---------------- 4+------------------------- + 


(IoT) - This requirement is for interoperability with IoT. 


AUTH_NONE has been downgraded from MAY in [RFC7321] to MUST NOT. The 
only case where AUTH_NONE is acceptable is when authenticated 
encryption algorithms are selected from Section 5. In all other 
cases, AUTH_NONE MUST NOT be selected. As ESP and AH both provide 
authentication, one may be tempted to combine these protocols to 
provide authentication. As mentioned by [RFC7321], it is NOT 
RECOMMENDED to use ESP with NULL authentication (with non- 
authenticated encryption) in conjunction with AH; some configurations 
of this combination of services have been shown to be insecure 
[PD10]. In addition, AUTH_NONE authentication cannot be combined 
with ESP NULL encryption. 


AUTH_HMAC_MD5_96 and AUTH_KPDK_MD5 were not mentioned in [RFC7321]. 
As MD5 is known to be vulnerable to collisions, these algorithms MUST 
NOT be used. 


AUTH_HMAC_SHA1_96 has been downgraded from MUST in [RFC7321] to MUST- 
as there is an industry-wide trend to deprecate its usage. 
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7. 


AUTH_DES_MAC was not mentioned in [RFC7321]. As DES is known to be 
vulnerable, it MUST NOT be used. 


AUTH_AES_XCBC_96 is set as SHOULD only in the scope of IoT, as IoT 

deployments tend to prefer AES-based Hashed Message Authentication 

Code (HMAC) functions in order to avoid implementing SHA2. For the 
wide VPN deployment, as it has not been widely adopted, it has been 
downgraded from SHOULD to MAY. 


AUTH_AES_128_GMAC status has been downgraded from SHOULD+ to MAY. 
Along with AUTH_AES_192_ GMAC and AUTH_AES_ 256 _GMAC, these algorithms 
should only be used for AH and not for ESP. If using ENCR_NULL, 
AUTH_HMAC_SHA2_256_128 is recommended for integrity. If using AES- 
GMAC in ESP without authentication, ENCR_NULL_AUTH_AES_GMAC is 
recommended. Therefore, these algorithms are kept at MAY. 


AUTH_HMAC_SHA2_256_128 was not mentioned in [RFC7321], as no 
SHA2-based authentication was mentioned. AUTH_HMAC_SHA2_ 256_128 MUST 
be implemented in order to replace AUTH_HMAC_SHA1_96. Note that due 
to a long standing common implementation bug of this algorithm that 
truncates the hash at 96 bits instead of 128 bits, it is recommended 
that implementations prefer AUTH_HMAC_SHA2_512_256 over 
AUTH_HMAC_SHA2_256_128 if they implement AUTH_HMAC_SHA2_512_256. 


AUTH_HMAC_SHA2_512_ 256 SHOULD be implemented as a future replacement 
of AUTH_HMAC_SHA2_ 256_128 or when stronger security is required. 
This value has been preferred to AUTH_HMAC_SHA2 384, as the 
additional overhead of AUTH_HMAC_SHA2_ 512 is negligible. 


ESP and AH Compression Algorithms 


4+---------------- 4+---------- 4+------------- + 

| Name | Status | Comment 

4+---------------- 4+---------- 4+------------- + 

| IPCOMP_OUI | MUST NOT | UNSPECIFIED | 

| IPCOMP_DEFLATE | MAY | [RFC3173] 

| IPCOMP_LZS | MAY | [RFC2395] 

| IPCOMP_LZJH | MAY | [RFC3051] | 

+---------------- 4+---------- 4+------------- + 
Compression was not mentioned in [RFC7321]. As it is not widely 


deployed, it remains optional and at the MAY level. 


Wouters, et al. Standards Track [Page 10] 


RFC 8221 ESP and AH Algorithm Requirements October 2017 


8. 


10. 


Summary of Changes from RFC 7321 


The following table summarizes the changes from RFC 7321. 


4------------------- 4+---------- 4+----------------- + 
| Algorithm | RFC 7321 | RFC 8221 | 
+------------------- 4+---------- 4+----------------- + 
| ENCR_AES_GCM_16 | SHOULD+ | MUST | 
ENCR_AES_CCM_8 MAY SHOULD 
ENCR_AES_CTR MAY MAY (*) 
| ENCR_3DES | MAY | SHOULD NOT | 
| AUTH_HMAC_SHA1_96 | MUST | MUST- | 
| AUTH_AES_128_GMAC | SHOULD+ | MAY | 
| AUTH_NONE | MAY | MUST / MUST NOT | 
4------------------- 4+---------- 4+----------------- + 


(*) This algorithm is not mentioned in the above sections, so it 
defaults to MAY. 


IANA Considerations 
This document does not require any IANA actions. 
Security Considerations 


The security of a system that uses cryptography depends on both the 
strength of the cryptographic algorithms chosen and the strength of 
the keys used with those algorithms. The security also depends on 
the engineering and administration of the protocol used by the system 
to ensure that there are no non-cryptographic ways to bypass the 
security of the overall system. 


This document concerns itself with the selection of cryptographic 
algorithms for the use of ESP and AH, specifically with the selection 
of mandatory-to-implement algorithms. The algorithms identified in 
this document as "MUST implement" or "SHOULD implement" are not known 
to be broken at the current time, and cryptographic research to date 
leads us to believe that they will likely remain secure into the 
foreseeable future. However, this is not necessarily forever. 
Therefore, we expect that revisions of that document will be issued 
from time to time to reflect the current best practice in this area. 
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